Various software tools facilitate the creation of user interfaces and other rich media content. For example, developers can use the Adobe® Flex® technologies to create Adobe® Flash® content using an XML-based markup language (i.e., MXML™) to declaratively build and lay out visual components. This declarative code can specify the visual attributes of the content, including the locations and display attributes of the content's visual components. The declarative code may be automatically generated based on a developer having graphically laid out components (e.g., buttons, etc.) on a displayed development canvas.
Adobe® Flex® version 2.0 has a View States feature allowing a developer to express how content or components vary as “state” changes. For a piece of content and/or each of the components within a piece of content, the feature allows a developer to enumerate a list of named states, and for each state, describe a delta of changes relative to a “base” state. FIG. 1 illustrates exemplary declarative code using a change-based syntax that could be used with Adobe® Flex® version 2.0 (prior art). The declarations 1 implement an exemplary Login/Register form by describing exemplary changes to the application's user interface upon changes of state. A “register” state is defined with the register state statements 2 and includes a list of changes to be applied to the base application state when the application changes to the register state. The statements for the login panel 3 specify that when an application user clicks on a “Need to Register” button, an event handler sets the view state to “Register.” The register state statements 2 add a TextInput control, change properties of the Panel container and Button control, remove the existing LinkButton control, and add a new LinkButton control.
While the Adobe® Flex® version 2.0 state syntax is expressive, there are various disadvantages to requiring that a developer specify a state in terms of changes to a base state. For example, in order to visualize a given state, a developer has to mentally visualize the base state and mentally implement the coded change instructions to that base state. In addition, because any component required in multiple states generally needs to be in the base state, developers are frequently required to use and keep track of complicated state hierarchy schemes, including multiple layer schemes, e.g., with a first state derived from a second state, the second state derived from a base state, etc.